Что-то я не пойму логики Time Packup...

Пробуем TimeBackup.

Имеем в качестве тестовой: одну директория (homes) общим весом в 32 Гб.

Включил TimeBackup

Назначение: usbshare1

Источник: homes

Включено расписание: "Включить резервирование по расписанию, каждый час с помощью SmartRecycle"

Из описания логики SmartResycle я так понял, что в каждую следующую сессию резервного копирования он пишет только изменения, таким образом экономя место. То есть сперва полное, потом только инкрементно.

Наблюдаю за бэкапами по адресу /usbshare/timeBackup/<Имянаса>/task<N>/

Там создано куча директорий (по дате и часу архивирования) в каждой из них по полному комплекту файлов из homes, каждый из которых весит 32 гига, то есть делается полный бэкап. Итого, за 14 часов бэкапирования одной единственной папки (в 32 гига весом) в бэкапах набежало 448 гигабайт хранения! То есть там 14 абсолютно одинаковых подпапок, совпадающих по размеру до байта. Что это? Что за фигня? Это экономия места на моем бэкап-хранилище? Другими словами, он делает каждый раз тотальный бэкап, затрачивая время работы, ресурс исходных дисков, место на результирующем диске. Это и есть новейшая продвинутая интеллектуальная логика бэкап-системы Синолоджи? Или я где-то не там галку поставил?

Вопроса три:

(1). что я сделал не так, что прет каждый раз полное бэкапирования, вместо изменений (которых на самом деле просто нет, то есть добавки должны быть - нулевые)?

(2). Если я буду бэкапировать общую папку емкостью в 1 терабайт (а у меня такие есть!) , то что, TimeBackup потребует 45 терабайт для хранения бэкапов? (ежечасно+ежедневно+еженедельно, как положено по SmartRecycle), или все образумится?

(3). Как все же делать нормальный, правильный бэкап этого синолоджи, в смысле правильный по схеме 1 полный а дальше инкрементные или дифференциальные копии?.... Сейчас там около 2 терабайт на NAS размещено, хотелось бы чтобы оно уместилось в имеющиеся ресурсы хранения бэкапов (3-х терабайтный внешний диск). А планируется довести объем хранения до 5-ти терабайт. Куда сливать в таком случае? Я планировал поставить второй NAS с дисками 3+3 Jbod, но если TimeBackup имеет такую логику как сейчас демонстрирует, то никаких десятков терабайт для бэкапов не хватит...Что делать?

Простите за сумбур в описании, я нахожусь в большом недоумении...

Если кто разъяснит логику работы этого TimeBackup в режиме SmartRecycle или без него, буду чрезвычайно благодарен.

Заранее спасибо.

продолжаю наблюдение

Исходная папка - 32 гб

По содержанию не изменяется.

Бэкапы с нее достигли 800 гигабайт... (25 папок по 32 гига каждая, все - как богатыри на подбор, одним и тем же объемом)

место на destination-диске закончилось...

Смотрим, что будет дальше.

Итак, шаг номер два.

Добавляем в исходную папку еще 120 гигов.

то есть симулируем активность пользователей.

Исходная папка выросла с 32 до 150 гигов. Места под архивы, напомню, 800 гигов. И всё оно занято аж 25-ю копиями одного и того же (25 копий х32ГБ) Хотим посмотреть, что будет делать синолоджи.....

И (трам-парам-парам"...) TimeBackup чтобы освободить место под архивы стирает три последних копии, самых свежих копии архива данных!

То есть, начинает удаление не со самых старых, из имеющихся 25-ти копий одного и того же, а удаляет несколько свежих, самых последних.

И правда - последние копии данных которые были доступны и через файловую систему, и через интерфейс Таймбэкапа - исчезли.

Если честно, у меня нет слов, одни матерные выражения.

Просто вредительство какое, со стороны программеров,

Любопытно, они хоть понимают, что напрограммирвали, и как система ведет себя в реальности?

Вот ведь вы дотошный человек! Мне и голову не пришла мысль проверять функционал, благо резервируемая папка невелика, а на разделе много места. Срочно чищу старые бекапы.

Спасибо!

Мне и голову не пришла мысль проверять функционал...

Всё гораздо интереснее, нежели мы предполагаем.

Проверять бэкапы нужно обязательно. Потому что...

TimeBackup отжег очередной раз.

Как место закончилось, он перестал порождать новые часовые бэкапы. Директорию новую создает (по текущему часу) но ничего в нее не пишет. Хотя, продолжал стирать старые часовые бэкапы по графику. В итоге мы имеем: все часовые бэкапы текущие за сутки - пустые. Хотя обязаны быть, задание-то неизменно. Другими словами, если кто надеется, что TimeBackup что-то там еще бэкапит на Вашем NASe - рекомендую проверить, а так ли это на самом деле. Ради интереса заглянул в журнал пакета. Он не на виду, но доступен в разделе центра пакетов. Давайте посмеемся вместе: "task [имя задачи] has failed to backup version [имя нового каталога с очередной копией] due to [error occurres while copying files]". То что места больше нет, для рожания очередных полных бэкапов - это программе неведомо. Предлагаю индусским программистам, или кто там эту поделку наваял (под которой Синолоджи подписалось) просто писать в журнале пакета: "кисо обиделось, бэкапить не буду, а причину найди сам".

Важное замечание.

Судя по всплывшей проблеме, верификации произведенного бэкапа в самом пакете нет. Иначе вывелось бы адекватное сообщение в "Уведомлениях...", мол бэкап не получился, проверьте состояние сервиса. Но уведомлений нет. Обычно верификация созданного бэкапа - стандартная функция в любом серьезном софте. Или, снова же, я невнимателен, и где-то галочку верификации не поставил? Попытался найти где... нету настройки. У родного синолоджевского пакета реальные проблемы в процессе работы, а NAS молчит. Причем в вопросе, прямо связанном с безопасностью и сохранностью данных.

Так что пока моя рекомендация - с большой осторожностью отнестись к заявленному функционалу в TimeBackup,

И, уже не надеяться на продвинутость программы (судя по случившемуся, она имеет довольно тупой интеллект).

А также проверить проверять периодически архивацию этим пакетом на Вашем NAS, если она включена.

__________________________________________________________

Версия TimeBackup: 1.2-2278, насколько понимаю, самая свежая.

Остается небольшая вероятность, что это печальное и случайное стечение обстоятельств,

комбинации мелких наложений проблем каждая из которых некритична,

но вместе по совокупности они рушат функционал.

Поэтому пакет сношу, директорию чищу, пакет ставлю заново,

и попробуем еще раз.

Прошу прощение за сарказм в предыдущем посте. Это я скорее от огорчения. Мне рекламировали Синолоджи как "решение, которое поставишь, быстро и легко настроишь, и не будешь иметь проблем", в отличие от установки собственного сервера и подбором и настройкой программ.... А также "повышенная стоимость девайса экономит твое дорогое время...".

Мне не улыбается тратить часы на выяснение какие косяки нас еще ожидают.

Хотелось бы поставить, включить и забыть.

А придется все же выяснять...

Итак, продолжаем.

Что удалось выяснить.

Эксперименты показали проблемы в несоответствии загруженной из центра пакетов версии TimeBackup имеющейся версии DSM. Вот так (несмотря на то, что загрузка осуществлялась непосредственно из центра пакетов работающего DSM)

Судя по всему, если вдруг выходит новая версия DSM (привет, 4.2!), то таймбэкап подстроен уже под нее заранее... Или бог знает, как там было устроено в рамках согласований загружаемых пакетов по отношению к текущей версии DSM. Загрузка пакета TimeBackup за несколько дней до официального выпуска следующей версии DSM встала на текущую актуальную DSM уже криво. У меня так получилось, что NAS был инициализирован за пару недель перед объявлением DSM4.2. И из центра пакетов скачан timebackup, который уже, возможно, успели модифицировать под новую модификацию DSM. При этом, данный пакет установился на DSM4.1 безо всяких оговорок, и даже не заикнувшись. Новый вариант таймбэкапа, молча и без претензий устанавливается из центра пакетов, молча начинает работать криво (или не работать вовсе). И всё это дело происходит тихо, мы не знаем что там происходит, работает-неработает, если работает как как...

В общем как это работало - описано выше. После обновления с DMS4.1 до 4.2 и переустановки timebackup, логика работы таймбэкапа стала именно той, что ожидалась изначально. Но, приходится держать ухо востро. При штатной работе (когда все отлажено) тоже все не шоколадно. Исходно я использовал тестовый каталог с 12969 файлов (216 гигабайт). В рамках верификации в востановленном (обратно из таймбэкапа) каталоге оказалось 12918 файлов. Причина понятна - какие-то файлы почему-то в бэкап не пишутся. Это файлы скорее всего с длинными именами или путями. Но, самое основное - мы не знаем какие файлы не пишутся. Всё происходит молча. Следов нет. Протокола ошибок записи файлов в архив - нет. Видимо, это фирменная фича такая. При этом формируется полная иллюзия устойчивости и бесперебойности.

Нет доклада - нет проблем!

Вердикт:

Если хотим предсказуемости, придется быть внимальным. Проверять функционал. Также настоятельно рекомендуется верифицировать бэкап путем восстановления в другое место и сверкой с исходником. Могут быть неожиданности.

_____________________________________________________

Если меня читают люди, которые могут контактировать с разработчиками.

В TimeBackup напрашиваются две вещи: (1) протокол ошибок копирования файлов (дефолтно включенный, но выключаемый по требованию). Чтобы любому сисадмину было ясно и понятно, какие файлы не попадают в бэкап и в каких заданиях, типа неправильное имя, слишком длинный путь и т.п. (2) Инициализация старта задания по событию "изменился состав директории".

Можно с настраиваемой задержкой старта задания (в пределах 1-60 минут) после данного события.

Спасибо за внимание.

У меня не работает как положено. На релизной DSM 4.2 переустановлен пакет 1.2-2278. Строчит бекапы по 690МБ (с нарастанием веса) как "пулеметчик за синий платочек". Никакого инкрементного копирования нет и в помине.

Пока на разделе остается много свободного места, не трепыхаюсь. Через несколько месяцев возьмусь за расчистку бекапов.

У меня не работает как положено. На релизной DSM 4.2 переустановлен пакет 1.2-2278. Строчит бекапы по 690МБ (с нарастанием веса)

Тут надо учитывать силу интеллекта логики хранения TimeBackup. Штатно она в размере папки показывает объем по каждой бэкапной сессии с учетом внутренних ярлыков (не зря они хотят EXT4 видимо, в качестве файловой системы) - то есть даже если добавляется чуть-чуть ежедневно или вообще ничего, размеры дневной (часовой папки) будут указываться полным объемом текущего бэкапа включая инкрементные изменения.

Например:

У нас стабильная по содержанию исходная папка в 200 гигов.

Жесткий диск, на который сливается бэкап пусть будет 1000 гигов.

ТаймБэкап будет показывать следующие часовые папки:

12:00 - 200ГБ

13:00 - 200ГБ

14:00 - 200ГБ

15:00 - 200ГБ

... и т.д.

Но!

Общий объем диска, и остающееся пространство (смотрится в "панель управления - устройства и принтеры - вывести информацию) будет оставаться практически неизменным.

Таким образом, штатно для нас важен контроль объема оставшегося дискового пространства а не большие размеры папок каждого "инкрементного" бэкапа. Они штатно "врут" в большую сторону. "Инкрементный" и "врут" я взял в кавычки, потому что это не совсем инкрементность, и не совсем вранье, но для пользователя тут есть такая особенность, которую следует учитывать. Гораздо хуже, если новые создаваемые папки ТаймБэкапа будут значительно отличаться от предыдущих в меньшую сторону, например у них будет нулевой объем (как было в моем случае, когда диск реально физически заполнился). Или они вообще создаваться не будут. В общем, стоит просто контролировать общий оставшийся объем диска для Destination или поставить уведомления на событие, скажем "осталось 10% от свободного объема" в "Панель управления - Уведомления - Дополнительно". А также периодически посматривать на объем создаваемых папок. Он должен быть не меньше, чем объем резервируемого источника.

hafis

Огромное спасибо за подробности!

Прошу прощение за сарказм в предыдущем посте. Это я скорее от огорчения. Мне рекламировали Синолоджи как "решение, которое поставишь, быстро и легко настроишь, и не будешь иметь проблем", в отличие от установки собственного сервера и подбором и настройкой программ.... А также "повышенная стоимость девайса экономит твое дорогое время...".

Мне не улыбается тратить часы на выяснение какие косяки нас еще ожидают.

Хотелось бы поставить, включить и забыть.

А придется все же выяснять...

К чему пришли? На чем остановились, как сейчас выполняете бекап?

hafis, у меня к Вам может быть не совсем умный вопрос, но я его задам. А чем Вас не устраивает функция резервирование/восстановление, которая сразу встроена в любую версию DSM, а TimeBackup - это отдельный бесплатный продукт, за качество которого Sunology не особо стремиться отвечать?

Дело в том, что мне приходилось пользоваться функцией резервирование/восстановление на DS110j c DSM 2.3-1157, когда я менял жесткий диск. Вставил новый жесткий, запустил восстановление с внешнего диска и у меня всё восстановилось и заработало без проблем.

Т.е. Вам так нужен этот TimeBackup и чем он должен был быть лучше обычной встроенной функции резервирование/восстановление???

А чем Вас не устраивает функция резервирование/восстановление, которая сразу встроена в любую версию DSM

Не устраивает отсутствием истории изменений архивируемых файлов.

Например пользователь (Вы сами) случайно удалили файл, или изменили его не так как хотели, или он просто испортился. Потом произошла работа встроенной функции резервирования. Файл - потерян навсегда.

Хорошая система бэкапа обычно способна вести историю изменений, на определенную глубину версий файла или времени бэкапов. Система резервирования, втроенная в DSM, этого не умеет.

Т.е. Вам так нужен этот TimeBackup...

Мне - нужен. Возможно для одинокого домашнего пользователя он не так актуален. Но, у меня на Синолоджи висят полсотни пользователей. И, наличие механизма архивирования типа "тайммашины" или "теневой копии" (в терминологии винды) - весьма полезно.

а TimeBackup - это отдельный бесплатный продукт, за качество которого Sunology не особо стремиться отвечать?

Идеологически, для пользователя продукции Синолоджи TimeBackup бесплатен или платен ровно в той же степени, в каковой бесплатно или платно встроенное резервирование в DSM. Вы все это - оплачиваете заранее и сразу, покупая сам девайс за мягко говоря немалые деньги. Оплачивая вопросы совместимости и работоспособности. В стоимость заложена как стоимость ОС, так и стоимость тестирования пакетов, официально одобренных Синолоджей. И, работоспособность сторонних пакетов, официально одобренных и дистрибутируемых самой Синолоджи - не менее важный фактор в принципиальном выборе оборудования на рынке, которое мы покупаем. К примеру, я оплатил порядка 100 тыс. руб за аппарат Синолоджи, который выполняет в одном из офисов функции почтового сервера. С помощью, того самого отдельного "бесплатного" (как полагаете) пакета. Но, если этот отдельный бесплатный продукт не будет работать как нужно на купленном совсем недешево девайсе, это означает, что деньги на продукцию Синолоджи будут в таком случае потрачены зря. И, лучше было бы потратить ту же сумму на полноценный сервер гораздо большей мощности. Между тем, мы покупаем вполне слабомощный Синолоджи, потому что остальное в цене - это стоимость безпроблемности софта для пользователя. И, техподдержка Синолоджи отвечает за функционирование этих пакетов, и это идеологически правильно.